The new inittab format
~~~~~~~~~~~~~~~~~~~~~~
Up to some point during development, sninit used sysvinit-style
inittab format ("sysvtab" for short):

	name:rlvls:action:command

Later on, the format has been changed to crontab-style "newtab":

	name	runflags    command

Note whitespace-separated fields, and runflags in place of rlvls
and action.


Why a new format?
~~~~~~~~~~~~~~~~~
Less ugly and better fitting sninit's internal representation.

The initial idea of sninit features called for a rather elaborate
per-entry configuration. Back then, having one field for runlevels
and another one for comma-separated list of value kinda made sense.

	httpd:2345:respawn,uid=apache,gid=apache:/sbin/httpd

As development progressed, some things became silent defaults and
other have been moved out of init (into run(8)), so a typical
respawning entry became
	
	httpd:::/sbin/runcap apache@apache /sbin/httpd

and one-time entries started to look like

	::wait:/sbin/whatever

so it made less and less sense to shoehorn it into sysvinit format,
pretty ugly to begin with.

Wherever things may be aligned, it's better to keep them aligned, so : were
replaced with whitespace separators. And since sninit had already crontab-style
environment variables, the whole thing started to look more like crontab.


Compatibility
~~~~~~~~~~~~~
sninit is not a drop-in replacement for sysvinit, and was not meant to be.
Switching from sysvinit to sninit requires rewriting inittab in any case,
so the idea of maintaining sysv-inittab compatibility has been rejected.


Field order
~~~~~~~~~~~
SysV-style field order (name-...-command) has been kept intact.
Command is the most variable part, so there is no other place to put it.
Between flags-name- and name-flags-, the latter has been chosen
to faciliate simple grep/sed operations on entry names:

	/^name\>/

Matching the 2nd field would require explicit pattern for the flags.
And this way unnamed entries come out naturally as matching ^\s.


Entry flags
~~~~~~~~~~~
Sysvinit uses self-descriptive keywords for its action field,
and a separate mandatory field for runlevels:

	mount:12345:wait:/bin/mount -a

In sninit, the visible part is nearly the same:

	mount	W12345	/bin/mount -a

but internal representation is different. For instance, W (wait) sets
two bits in flags, C_WAIT and C_ONCE. There are also R which sets C_ONCE
only, and L which sets C_WAIT without C_ONCE.

Why this discrepancy? Well, the internal bitflags work well internally,
and with rare exceptions they are independent and trigger different
conditions in different parts of initpass(). However, not all flag combinations
make sense, and individual flags are really hard to document without turning
to initpass source.

So instead, useful bitflag combinations are given specific codes (W, R, S etc)
and those happen to work a lot like sysvinit actions.
